Hello, my program needs to know, if another user did change objects or anything else in the module and didn´t save yet.
1. Is it possible with dxl to find out, if there are unsaved changes in a module on another DOORS Client?
The function "unsaved(m)" only returns true, when the changes were made in the same client. It ignores changes that were made in a different client.
2. Is it possible to find out, at which time these changes were made?
I couldn´t get a history record for unsaved changes of another client.
3. DOORS creates a new History Session every time a client opens a module in shared or edit mode. Is it possible to find out, which sessions are still open?
Thank you very much in advance!
ThomasR. - Wed Jan 19 08:45:18 EST 2011 |
|
Re: unsaved changes on a different client
PDU - Thu Jan 20 01:16:50 EST 2011
Hi,
1. i think no.
2. i think no.
3. yes, see attached file.
Pierre
Attachments
attachment_14573171_UtilisateursConnectes.dxl
|
|
Re: unsaved changes on a different client
llandale - Thu Jan 20 15:00:02 EST 2011
Unless Mathias jumps in here to correct me, then I'm confident the answer to the first two questions is "no". I have no reason to suspect there is client-to-server activity associated with you modifying an object attr value; the activity begins when you "save".
Looking at the DXL response to #3, it appears you can deduce when a session is still open by looking at the active lock list. But if you look at the active lock list then you don't really care about the Sessions.
If you solve the problem of gracefully booting folks out of DOORS after so much inactivity or when maintenance is about to begin, you get the gold star.
|
|
Re: unsaved changes on a different client
ambes_gt - Fri Jan 21 03:07:39 EST 2011 llandale - Thu Jan 20 15:00:02 EST 2011
Unless Mathias jumps in here to correct me, then I'm confident the answer to the first two questions is "no". I have no reason to suspect there is client-to-server activity associated with you modifying an object attr value; the activity begins when you "save".
Looking at the DXL response to #3, it appears you can deduce when a session is still open by looking at the active lock list. But if you look at the active lock list then you don't really care about the Sessions.
If you solve the problem of gracefully booting folks out of DOORS after so much inactivity or when maintenance is about to begin, you get the gold star.
If you can not lock the object, there might be unsaved changes.
Perhaps this helps ...
|
|
Re: unsaved changes on a different client
PDU - Fri Jan 21 04:56:58 EST 2011 ambes_gt - Fri Jan 21 03:07:39 EST 2011
I think there might be an indirect way to check, or at least to verify there are no unsaved changes. If there are unsaved changes to an object by another client, the object must be locked. So if you can lock an object (and unlock it again), there are definitively no unsaved changes by other clients.
If you can not lock the object, there might be unsaved changes.
Perhaps this helps ...
server receive no information on objects change by client.
When a client open a module in exclusive edit, all module is locked.
Pierre
|
|
Re: unsaved changes on a different client
llandale - Fri Jan 21 14:43:17 EST 2011 ambes_gt - Fri Jan 21 03:07:39 EST 2011
I think there might be an indirect way to check, or at least to verify there are no unsaved changes. If there are unsaved changes to an object by another client, the object must be locked. So if you can lock an object (and unlock it again), there are definitively no unsaved changes by other clients.
If you can not lock the object, there might be unsaved changes.
Perhaps this helps ...
Further thoughts down this silly trail will lead us to compare the date of the shared lock with the last modified date of objects in a locked section, and you can therefore sometimes deduce whether they actually saved changes and when; but again you cannot deduce for sure when something has indeed changed.
If Tony would respond to this thread, he'd gleefully pull the plug on that dude who locked a module and went home, then remove his edit rights for a day just out of spite, then walk by his office and slap him upside the head. That would indeed resolve the problem effectively.
|
|
Re: unsaved changes on a different client
ThomasR. - Mon Jan 24 05:30:34 EST 2011
Hi again and thanks for your help.
It would be great if the program could find out that there are unsaved changes and the date and time of the first change. However the main purpose is to find out, till which date and time there are definitely no unsaved changes.
So if I know for sure that before a specific date there are definitely no unsaved changes, I would be glad (Of course this date should be as late as possible. It doesn´t help to know that there is definitely no unsaved change when you go back one month - hope the users are intelligent enough to close the modules at least every couple of days). Although it would be nice and improve efficiency, it is not absolutely neccessary to know, if there are really unsaved changes. All I need to know is that before the returned date, there is definitely no unsaved change.
Maybe it is easier to find the first date and time when a module was opened in share or edit mode and was not closed (or changed to read mode) yet?
|
|
Re: unsaved changes on a different client
Mathias Mamsch - Mon Jan 24 07:47:27 EST 2011 llandale - Fri Jan 21 14:43:17 EST 2011
This is all "might be" changed. Yes, you can lock/unlock when the other has the module open Shared and deduce some things that have NOT been changed, but you cannot Deduce what has in fact been changed.
Further thoughts down this silly trail will lead us to compare the date of the shared lock with the last modified date of objects in a locked section, and you can therefore sometimes deduce whether they actually saved changes and when; but again you cannot deduce for sure when something has indeed changed.
If Tony would respond to this thread, he'd gleefully pull the plug on that dude who locked a module and went home, then remove his edit rights for a day just out of spite, then walk by his office and slap him upside the head. That would indeed resolve the problem effectively.
Opinions anyone?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: unsaved changes on a different client
llandale - Mon Jan 24 17:23:18 EST 2011 Mathias Mamsch - Mon Jan 24 07:47:27 EST 2011
I would really like to attach a "Timer" to the Database Explorer which regularly stores status information about opened modules and unsaved sessions to a central data storage. As long as it is not about "detecting inactivity" (like the user making no mouse movements), this should not be so hard.
Opinions anyone?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
[] Query all open modules in the database and issue "unsaved(mod)". I have a nagging memory of detecting a case where the module was indeed changed but "unsaved" returned false.
[] for "unsaved" modules, query all objects to determine which are "unsaved(obj)" and query their Last Modified Date.
[] Record the "lastSelectedModule" and "lastSelectedObject" and "current Module" and "current Object". And list of open modules. If none of that changes be willing to suspect nothing is happening on the client.
[] Admin can set a config file flag indicating desire to shut down the database. Your clever timer code on the client could determine that shut-down is requested, and take action, as best can be determined, to accomodate that gracefully. Perhaps display "Save and Close in 5 minutes" dialog. Perhaps downgrade any module opened Shared or Edit. When the time is up, save and close everything then exit.
[] Perhaps this info can be stored on the client, but the client records the fact that the timer is in fact running on the database. The Database shut-down script lets timer-active clients shut down their clients gracefully, but at the end of the road will rudely abort residual clients, including those that have disabled their timer.
[] I wonder if you can query the Windows Process number of CPU cycles for "doors.application" in order to deduce the activity or inactivity of the DOORS client.
|
|
Re: unsaved changes on a different client
Mathias Mamsch - Tue Jan 25 03:08:09 EST 2011 ThomasR. - Mon Jan 24 05:30:34 EST 2011
Hi again and thanks for your help.
It would be great if the program could find out that there are unsaved changes and the date and time of the first change. However the main purpose is to find out, till which date and time there are definitely no unsaved changes.
So if I know for sure that before a specific date there are definitely no unsaved changes, I would be glad (Of course this date should be as late as possible. It doesn´t help to know that there is definitely no unsaved change when you go back one month - hope the users are intelligent enough to close the modules at least every couple of days). Although it would be nice and improve efficiency, it is not absolutely neccessary to know, if there are really unsaved changes. All I need to know is that before the returned date, there is definitely no unsaved change.
Maybe it is easier to find the first date and time when a module was opened in share or edit mode and was not closed (or changed to read mode) yet?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: unsaved changes on a different client
ThomasR. - Tue Jan 25 05:49:38 EST 2011 Mathias Mamsch - Tue Jan 25 03:08:09 EST 2011
If you only want to find the date and time of the last (saved) modification, why don't you just read the "Last Modified" date? It should reflect the last change, that was saved to the module.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
I need the date and time when I still can be sure that there were no unsaved changes in a module.
There could be a case where (in shared edit) user A changes some objects at time A1, then user B changes some objects at time B1 and saves at time B2. "Last Modified" would return the date B1 (+ not accurate, see below), but I need the time A1 or at least the time A0 when user A opened the module.
Example:
A opens module in shared mode (A0) -> B opens module in shared mode(B0) -> A changes some objects (A1) -> B changes some objects (B1) -> B saves (B2) -> skript runs
Skript should return A1 (best case) or at least A0 (acceptable if users don´t open in shared or exclusive edit mode for a long time without closing the module)
By the way: The accuracy of "Last Modified" seems to be limited to days, once the module was closed. I tried to use it for a different problem a few weeks ago, too. Only with history records I could get the accurate Date and time, accurate to seconds.
@Louie: unsaved(m) only returns when the unsaved changes are in the same client, not when another client did not save its changes. The script I am working on, will not run on every client. The client that runs the skript must find out if other clients have unsaved changes in the same module that he wants to use.
Please correct me, if I got something wrong.
|
|
Re: unsaved changes on a different client
llandale - Tue Jan 25 09:46:25 EST 2011 ThomasR. - Tue Jan 25 05:49:38 EST 2011
Hello again,
I need the date and time when I still can be sure that there were no unsaved changes in a module.
There could be a case where (in shared edit) user A changes some objects at time A1, then user B changes some objects at time B1 and saves at time B2. "Last Modified" would return the date B1 (+ not accurate, see below), but I need the time A1 or at least the time A0 when user A opened the module.
Example:
A opens module in shared mode (A0) -> B opens module in shared mode(B0) -> A changes some objects (A1) -> B changes some objects (B1) -> B saves (B2) -> skript runs
Skript should return A1 (best case) or at least A0 (acceptable if users don´t open in shared or exclusive edit mode for a long time without closing the module)
By the way: The accuracy of "Last Modified" seems to be limited to days, once the module was closed. I tried to use it for a different problem a few weeks ago, too. Only with history records I could get the accurate Date and time, accurate to seconds.
@Louie: unsaved(m) only returns when the unsaved changes are in the same client, not when another client did not save its changes. The script I am working on, will not run on every client. The client that runs the skript must find out if other clients have unsaved changes in the same module that he wants to use.
Please correct me, if I got something wrong.
This notion may make sense if you figure to want to shut down the other client gracefully; which is tough since you cannot command an idle client to "save" from afar.
However, if you figure to be doing some other chore, then there is doubt that you should consider changes made to an unsaved module over there, as there is no guarantee that the changes will be saved. So it appears you are running a report on the last time the module was modified, so you end up with a line that says "At XYZ time the last modified date was ABC". With my method (ignore unsaved changes), its possible that the module is saved after XYZ which would increase ABC, throwing off the report the next time. With your method (I presume, try to find unsaved changes) then your report is off when they don't save.
A solution is to kill the other client process (disconnect from database), which is tough luck for the unsaved Dude but makes your reports accurate.
So, I guess the solution will resolve around whether Mathias can figure out a way to command a client to "save" and then "close" from another client; and whether he really wants to let folks know even if he ever figures it out.
|
|
Re: unsaved changes on a different client
Mathias Mamsch - Wed Jan 26 12:52:08 EST 2011 llandale - Tue Jan 25 09:46:25 EST 2011
We've been telling you that you cannot reach out to the other client and do queries like that. Mathias had some notion of some background script running on EVERY client that logs what that client is doing, presumably there would be some master script YOU could run to query that log file to deduce what the other folks must be doing. I provided some random thoughts on that subject.
This notion may make sense if you figure to want to shut down the other client gracefully; which is tough since you cannot command an idle client to "save" from afar.
However, if you figure to be doing some other chore, then there is doubt that you should consider changes made to an unsaved module over there, as there is no guarantee that the changes will be saved. So it appears you are running a report on the last time the module was modified, so you end up with a line that says "At XYZ time the last modified date was ABC". With my method (ignore unsaved changes), its possible that the module is saved after XYZ which would increase ABC, throwing off the report the next time. With your method (I presume, try to find unsaved changes) then your report is off when they don't save.
A solution is to kill the other client process (disconnect from database), which is tough luck for the unsaved Dude but makes your reports accurate.
So, I guess the solution will resolve around whether Mathias can figure out a way to command a client to "save" and then "close" from another client; and whether he really wants to let folks know even if he ever figures it out.
Experimenting with a timer on the database explorer seems to work nicely. Just put the below in a file in "\lib\dxl\config\baseWindowCallbackFiles". It will be executed from the database explorer and start a timer, which will whenever it detects that you opened a module do an analysis and shutdown your client after some time, if it gets the command from the "master command file"
NOTE: to be implemented properly. Also check that the license will be returned after a call to 'exit_'
Regards, Mathias
//
/*
*/
bool shutDown = false
void readMasterCommandFile () {
// read that from the master command file
string command = "SHUTDOWN THOSE SHEEPS!"
if (command == "SHUTDOWN THOSE SHEEPS!") {
print "Shutting down in 10 ..."
shutDown = true
}
}
void writeResultsToLog () {
print "Writing a global log file ... "
print "Or some stuff to the config area ... "
print "Or whatever\n "
}
void myCallback (DBE time) {
if (shutDown) exit_
print "Iterating over open modules ...\n"
Module m
bool foundOne = false
for m in database do {
print "Uh you got " (fullName m) (versionString moduleVersion m) " open!\n"
print "Checking for unsaved changes ...\n"
foundOne = true
}
if (foundOne) {
writeResultsToLog ()
readMasterCommandFile ()
}
}
DBE myTimer = timer (dbExplorer, 10.0, myCallback, "string")
print "Starting tha timer:" (startTimer myTimer) "\n"
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|